Now that we've signed our app, we can move on to implementing app updates.
This is, of course, an extremely important feature as it allows us to fix bugs or make improvements
to our app and automatically have existing abuser's update to that newer version.
Essentially, there's two ways this can happen, depending on how the end user has installed your app.
The first option is that you've published your app to an app store like the Mac App Store, in which
case the operating system takes care of updates.
When you have a new version, you simply publish that to the App Store and the users are notified and
updated.
So out of our hands and nothing to do with the app itself.
The second being that you've distributed your app directly to the end user, not through an official
app store.
In this case, we need built-In functionality to check for updates each time the user launches the app
and install the latest should there be any available to do this.
Electron provides us a built in module called Auto Updater, but we won't be using this one.
Instead will use Electron Boulder's own far superior auto update a module.
The main difference being that electrons updater requires a dedicated update server, an extra piece
of complexity and maintenance we can really do without instead.
Then Electron Balde allows updates to be hosted on GitHub.
Ben, try Amazon S3 or even Digital Oceans Spaces will be looking at GitHub or more specifically, GitHub
releases.
Releases on GitHub is part of any standard code repo and free, for example, on the project code repo,
which I'll use as a release server for the Read It app.
We can find releases here again.
Each repo has its own releases.
The way Electron Balde determines which repo to check for releases then is by the repository field in
the project package or JSON file this year.
So make sure this is set to your apps.
GitHub Repo.
I already have the set to the repo.
I'll be using.
Also note that electron builder supports both public and private repos and you don't necessarily have
to commit your OPKO to the repo in order to use it for releases.
I obviously have the project code in this repo, but should you wish to use a free public repo like
this without committing your up code?
Just create one and commit a simple README file.
The app code is not needed.
OK, navigator releases.
I don't have any, so go ahead and create a new release.
We'll have to set the release info first thing being the tag version, this being because each time
you create a release, GitHub will also create a tag for that release or rather of the repo at that
point in time.
Very important, however, is the naming of this tag version.
This should match the release version of your app as set in the package Dodgson file when building it,
which in the case of this version will write as V for version one point zero point zero.
I'd also suggest sticking to semantic versioning of major version being the first number, minor version,
the second and any patch version or bug fixes the third number.
I've linked to an explanation of semantic versioning in the lessened resources.
If you're not familiar with it, then we can give this release a meaningful title.
I'll say first release.
And a changelog in the released description, the format doesn't really matter, but some bullet point
is good fixes bug and adds feature X.
That's all we need for now.
We won't be uploading the releases ourself.
Electron Boulder will take care of that for us.
All we are doing here is to give Electron Boulder a draft release to update the new bill too.
So save this as a draft there.
This is now ready, not published, but ready for Electron Boulder to upload a new release bill too.
Before we can do that, however, we'll need to give Electron Boulder access to this repo in order to
upload the Newbold's.
To do this, we'll have to create a unique personal access token personal being.
The key here, this is essentially going to provide the same access you have.
It's not repo specific then to do this, navigate to your settings.
Yeah.
Developer settings on the left.
Personal access tokens.
Generate a new token, which will prompt you for your password to confirm.
Give this token a memorable name, I'll call it reedit releases.
Then by default, this token doesn't have access to anything, so we have to tell Giddyap what scopes
of access to Grant, the bearer of this token for electron builder to upload releases, it only needs
repo access here.
This first one with all of the associated sub scopes generate token.
And there is this token will only appear once, so as soon as this page is closed or reloaded, you
won't be able to see the token again.
So copy it.
And where I'll save mine is in that same private directory I have the cert files in, so in the project
directory.
Right, the token to a simple text file with echo the token as a string, so wrapping it in quotes to
private G.H. underscore token dot text, underscore Tolkan being the environment variable will assign
this token to when building a new release.
This way of storing the token is by no means a requirement.
Just store the token somewhere safe where you can easily access it when building your app.
OK, now we have our first release drafted and an access token for GitHub.
We can configure Electron Balde to use GitHub as the release server for read it back on the auto update
guide.
We can find the documentation to do this here.
Publish configuration being this last section here and the docs.
First thing to take note of here is that when we set a underscored token environment variable when building
our project, the provider will automatically be GitHub, which is exactly what we'll be doing.
Hence the reason we save that GetUp token to a file of this name.
Then the next thing is to set the publish key.
This can contain a number of providers in a reform, but that's typically not required.
You can also set this key on a platform specific basis, so potentially releasing different versions
of your app to different providers.
Again, not a common scenario in our case.
Then we can simply set a common publish key on the electron, a configuration over to packaged ojisan.
I'll first get rid of the Mac targets.
Leaving targets to the default is what we want for independent distribution.
And on this build object, create a publish key.
With the global public provider being GitHub, so applying to all our Bolds, Mac, Windows and Linux,
that's basically it for configuring GitHub releases as the updates server next.
Then we can add a new run script to also publish a new bould in the scripts object set a new command
called Release.
On which I'll execute electron builder.
Bold or just leave it out again for Mac, Windows and Linux, as a new release will likely be applicable
to all platforms.
I'll just make it Mac only for demonstration purposes, though, and most importantly, tell Electron
Builder under what conditions to publish this new build.
We set that on the public flag or P in shorthand.
And as this flag requires a value, we have four options back on the published box.
Yeah, these are the four possible values we can pass to Electron Baldor on that public flag untag,
meaning if a tag for this version of the app exists in the repo on tag or draft.
So same as the first, but also if a draft exists, which is what we have always, as the name suggests,
create the release every time for the bold.
And lastly, never a bit of a redundant option, as mentioned, will want to use this on tag or draft
option.
So copy that.
And if this is a bit confusing, all it means is that should the specified release server GitHub, in
our case contain a tag or a draft for the version being built, upload this bill to that, release a
release and a tag is essentially the same thing.
When you create a release on GitHub, your repo is tagged at that point.
The main difference then in allowing either a tag or a draft is that we get to publish the release manually
after it's uploaded.
It avoids having a published release without any Boult uploaded to it.
In other words, what we expect to happen now is that when we build our project, Electron Baldor will
check for a matching version, release or tag on GitHub.
This one here upload the build target to that release.
As you can see, this can also be done manually here.
And then after that, when we are ready, we can simply go and hit, publish, release.
We can add that publish value copied from the docs in quotes, untag or draft.
That's our command to publish or release a new bould.
We can test this still building version one.
That's the version we created our release on GitHub for over to the terminal calling NPM Run release
that new run script.
But in order to allow Electron Builder to upload our Newble to GitHub, we also have to provide our
GitHub access token.
This one here, safe to underscore token.
And if you recall, the reason I saved it to this file name is that G.H. Underscore Tolkan is the name
of the environment variable we have to set with this token value to do that prepend to this release
command.
G.H. underscore token equal this token value as a string.
There, if you're on windows, the equivalent of this will be set X G.H. underscore Tolkan with the
token value.
So this way, we're only ever setting the token when performing a release, but essentially keeping
it secure, OK, run this, which performs the Makled as we've seen it previously.
But this time, as soon as the bolt is done, I'll forward to that.
We get this publishing step to GitHub, the master electron repo version, one point zero point zero,
at which point electron builder will start uploading the Newbold's to that draft release that matches
the version of this bolt.
These outputs can sometimes be a bit inconsistent and coarse artifacts like this one, but it's just
the output.
As you can see, that line is just continuing here now.
I'll skip through this again and done all of our new version, one, make targets has now been uploaded
to the draft released on GitHub.
Check that back to releases.
Where we now have four assets click to expand those.
And they read it version one, zip, a DMG and two auxiliary files used by the auto updater when checking
for a new update, this one year latest Mac being the most important.
Inspect that file in the project.
Latest Mac Dot Yamal, which holds all the information electron Boulder's auto update.
A module needs to download and verify one of these Mac released targets from GitHub.
And of course, as we can see here, we still have the new build in the directory as before.
No change there.
OK, so that worked.
But at the moment this release is still a draft, which is what we wanted.
We're now sure everything worked and the app Target was uploaded successfully so we can publish this
release, edit the draft.
And right at the bottom, publish, release.
And that's done, this release is now available and can be used by electron builders, auto updater
to update an app with a version lower than one point zero point zero.
We've, of course, not implemented auto update yet.
So in the next lesson, we'll do that and see how this update is found and used.